This assumes tags of the form "0.9.2" (no leading 'v'), which is what we've been using in rand.

Maybe it's worth to switch to the v0.9.2 tagging scheme? I think it's much more popular across Rust crates.

I only really see disadvantages of the v* notation (the exception being the more complex pattern matching used in this PR).

The job isn't running on newly pushed tags which should match the given pattern. Do you know how to debug this?

Spec: https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#filter-pattern-cheat-sheet

It looks like you've missed one indentation level after line 25, which causes the following error:

(Line: 25, Col: 7): There's not enough info to determine what you meant. Add one of these properties: run, shell, uses, with, working-directory, (Line: 28, Col: 5): Unexpected value 'run'

Hm, no. I was wrong. The config in master looks correct.

The regexp may be incorrect. I get the following error for * on regex101.com:

* The preceding token is not quantifiable

Also note that your forgot the cargo publish part. Was it intentional?

This is some form of glob pattern not a regexp. That's part of the problem.

No, I didn't publish; I just pushed a couple of old tags.

Try to remove * and see whether it would get triggered by pushing tag for 0.2.0? It obviously would not work for pre-releases, but we would at least check whether * causes issues or not.

No dice. I'll try with a 'v' prefix.

I pushed v0.0.0 tag to the latest master commit and it triggered the workflow. So it seems it may not work on older commits for some reason.

Oh... I wondered where that came from.

I think I understand why the workflow does not get triggered. GH looks for configs in the commit itself, so if we tag an older commit, GH thinks that there is no such workflow.

Confirmed: tagging 0.10.0-rc-1 works since this matches what was in release.yml at the time.

BTW release names (i.e "release_0.10.0-rc-1") look a bit ugly in my opinion.